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Abstract 


This document describes the administrative procedures for networks 
seeking to connect to the global Internet. This includes the steps 
and operations necessary for address space allocation and 
registration, routing database registration, and domain name 
registration. The document also contains information about the 
required forms and how to obtain them. 
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Who Should Read This Document 


This document is intended for system engineers and technical managers 
of networks who want to make a connection to the Internet. It 
assumes a basic knowledge of the Internet and networking. 


This information is intended to help new or expanding networks 
understand and follow the Internet administrative procedures, and to 
provide assistance in filling out the various templates and 
registration forms. Appendix D is a glossary of acronyms. 
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Checklist 
This document will explain the following procedures: 


o Determine your organization type and current status. 

o Determine your administrative and technical contacts. 
Determine your budget (and chargeback system) and choice of 
carriers. 

Determine to whom you will connect. 

Predict your current and projected address space needs. 
Set-up your system to connect. 

Request and register your address space allocation. 

Request and register an autonomous system number, if needed. 
Register with a routing database, if needed. 

Register your country’s domain name, if needed. 

Request and register your IN-ADDR.ARPA domain name, if needed. 


O 


00 000000 


Prerequisites 


This document assumes that you have examined different alternatives 
for physical connectivity and will assist you in navigating the 
Internet infrastructure so that you can use that connectivity. In 
choosing your upstream provider, you should consider their ability to 
deal with the Internet infrastructure. 


What will you be doing and what role will you play? 


o If you are interested in connecting yourself (or a small 
organization), you are an Internet end user. You will probably 
want to contact an Internet Service Provider (ISP) for most of 
your needs. Read section I and the first part of section II. 


o If you are interested in connecting your organization and in 
having address space to distribute within your network, you are an 
Internet high volume end user. You will need more address space, 
but still may chose to work with an Internet Service Provider 
(ISP) for most of your needs. Read sections I and II. 


o If you are interested in connecting your organization, and in 
distributing addresses to your clients (who are end users), you 
are an Internet Service Provider (ISP). You will need to contact 
a Local Internet Registry (if one is available, or your upstream 
provider). Read section I and continue reading the rest of this 
document. 
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o If you are interested in distributing addresses to your clients 
and your clients are in turn distributing addresses, you are a 
Local Internet Registry or large ISP. You will probably need to 
contact the Regional Internet Registry in your geographical area. 
Read section I and continue reading the rest of this document. 


I; Preparation of Systems and Network Planning 


STEP ONE: PREPARE INFORMATION, ORGANIZE HARDWARE, FIGURE OUT TO WHOM 
YOU WILL CONNECT, AND TEST IN-COUNTRY SYSTEMS. 


A. What do I need to connect to the Internet? 


You can connect using dial-up or dedicated lines, and you can choose 
UUCP or IP. It is preferable to be running the UNIX operating system 
with TCP/IP over a dedicated line, although you can begin by using 
UUCP over a dial-up line. Although there are alternatives to UNIX, 
for historical reasons and robustness UNIX is better prepared to 


handle Internet connectivity. It is best to use TCP/IP inside your 
network even if you use another method for your external 
connectivity. 


You will need to obtain an Internet Protocol (IP) address, or block 
of addresses, and a domain name. You may also need an Autonomous 
System Number (ASN) and an IN-ADDR.ARPA (reverse addressing) domain 
name. However, you may begin by having dial-up connectivity to 
another organization that supports one or more mail exchange (MX) 


record(s) for your site. This would allow you to receive email at 
your own domain name without requiring you to invest as much 
initially. 


B. What connectivity medium should I choose? 
You may be constrained by telecommunications regulations in your 
country as to your choice of dial-up, digital phone lines, fiber 
optic cable, or satellite suppliers. If not, cost, bandwidth, and 
reliability will determine your choice. 

C. What else do I need to do? 


Before you do anything else: 


1. Designate an administrative contact person and a technical contact 
person. 


Choose one person to be the administrative contact and another person 


to be the technical contact. Write down their full names, email and 
postal addresses, and telephone and fax numbers (with country 
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prefixes in the form + country code (e.g., +011), city code, and 
local telephone number). The administrative contact should be a 
member of your organization and must reside in the country. The 
technical contact should be the key network support person and may be 
represented initially by someone outside of the country. Note that 
the technical contact must transition to a network support person 
residing in the country. The Internet Registries will request this 
information in the form of database entries called objects. For 
example, on the RIPE template, the administrative contact should be 
listed in the admin-c field in the database objects, and the 
technical contact in the tech-c field in the database objects (more 
information on database objects follows in section II D below). 


2. Determine your cost-recovery charging scheme, if needed, so that 
you can sustain operations. 


No form or record will specifically request this, but it is important 
that you project your costs adequately so that you can assess fees to 


cover them and ensure stability of operations. 


3. Diagram your network topology. 


Determine the number of groups and end users. Describe the size and 
shape of your current network. Design your addressing plan based on 
this information. It may be helpful to consider your organization 
chart when doing this, if you anticipate it to be fairly stable. 


If you are restricted to using the local telecommunications company’s 
telephone circuit, choose your circuit carrier based on capacity and 
where it lands geographically. Consider an asymmetric circuit, e.g., 
128kbps in and 64kbps out, if you expect to have more incoming 
traffic than outgoing (e.g., if most of the traffic is expected to 
originate from web servers outside your network). 


4. Determine to whom you will connect. 


See the prerequisites section for types of connection providers that 
might be appropriate for your situation. Determine which ISP or 
telecommunications company best fits your connectivity needs. 


5. Predict your address space and bandwidth requirements from end 
user needs. 


Since address space is finite and must be conserved, end users are 
not permitted to reserve address space. Address space is based on 
what your needs are and how you justify those needs. Evaluation of 
IP address space requests is usually based on the documentation you 
provide for the following 24 months (as per RFC 2050), as specified 
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in the address space usage template and in the addressing plan you 
submit. Once you have used your assigned address space, you can 
request additional space based on an updated estimate of growth in 
your network. This usually includes detailed documentation, updating 
the appropriate regional registry database with details of your end 
user assignments, and assigning address space both conservatively and 
efficiently. 


You will need to justify your needs for address space by 
communicating your network design and should be prepared to clearly 
present your plan for effective use of the request. Determine your 
current and future user needs. If you are offering virtual web 
services, it is no longer necessary to assign one IP address per 
domain. HTTP/1.1 defines the "host" header to allow vanity names 
without the use of an IP address. Allocations for points of presence 
(POP) throughout your region should also be determined. Predictions 
of user behavior can be based on analysis of published rates, 
interviews with individual and institutional subscribers, and case 
histories of other countries (see "History of the Internet in 
Thailand"). For example, 


Areal 

10 dialup modems 

10 leased lines to organization’s LANs (size of the LANs) 
Area2 

5 dialup modems 
Main POP 

5 servers: mail, WWW, DNS, FTP, etc. 


When you design your plan, you should design it for what you need 
now, what you believe you will need six months from now, and then one 
year and two years from now. 

6. Set up, connect, and test your hardware and software. 

It is important to ensure that you have enough representative systems 
set up and their connectivity tested using temporary addresses before 
contacting the appropriate agency for address space. 


D. How do I get the documents referred to in this guide? 


See Appendix B for details on obtaining the documents referred to in 
this guide. 


E. Section References 


For more information on TCP/IP, see RFC 2151, "A Primer on Internet 
and TCP/IP Tools and Utilities". 
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II. 


Address Space Allocation 


STEP TWO: OBTAIN ADDRESS SPACE ALLOCATION AND REGISTRATION FROM THE 
ISP YOU ARE CONNECTING TO, OR (AS A LAST RESORT) YOUR REGIONAL 
REGISTRY. 


Internet Protocol (IP) addresses (under the current version 4) are 
32-bit numbers usually expressed as 4 octets in dotted decimal 
notation (for example, 128.223.162.27, which is the IP address for 
the Network Startup Resource Center (NSRC) web server at the time of 
this writing). Public IP addresses make up the Internet address 
space. Addresses are allocated in a hierarchical manner and are 
designed to be unique. 


The Internet Assigned Numbers Authority (IANA) allocates large 
address blocks to the three current Regional Internet Registries 
(IRs): ARIN, APNIC, and RIPE NCC which, in turn, allocate smaller 
blocks to Local Internet Registries or large ISPs. Local Internet 
Registries, which are typically ISPs or collections of ISPs 
represented at a country level, and large ISPs process the vast 
majority of address space assignments to ISPs and end users 


Contact the Internet service provider from whom you are getting your 
connectivity services (your upstream provider) with an address 
allocation request. It is important and required that you contact 
your upstream provider first, and not the Regional IR automatically. 
The first question the Regional Registry will ask you is why you 
cannot get address space from your upstream provider. 


Who is my upstream provider? 


If there is an ISP already functioning in your country, contact them 
directly. If you are to be the first connection in your country, you 
may need to contact your Regional IR in your geographic region, but 
you should always contact your upstream provider first for assistance 
and guidance. Since address allocation is hierarchical, the 
administrative organizations and procedures also represent this 
hierarchical structure. It is important not to skip a step in the 
hierarchy. Current Regional Registries include ARIN (the Americas, 
Caribbean, and Africa), RIPE (Europe, Africa, and the Middle East), 
and APNIC (the Pacific Rim and Asia). Contact information for these 
organizations is listed in Appendix A. 


You should contact your Regional Internet Registry if 1) the ISP you 
are connecting to is unable or unwilling to provide address space, or 
2) your particular connectivity requirements will result in non-local 
data to your customers possibly taking a different route over the 
Internet than data destined for your upstream provider’s customers, 
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or 3) you anticipate a quick growth rate that may require changing 
your current upstream provider to a larger one and you wish to avoid 
the renumbering that such a move would require. 


B. How much address space should I ask for? 


Regional IRs typically assign address blocks on the basis of an 
immediate need and projected utilization rate within one year. (If 
you are in the ARIN region, it is one year for end user organizations 
and three months for ISPs.) Calculate your address space request 
accordingly. It is recommended to include the organization chart and 
network topology diagram referred to in section I.C, number 3 
(above). Note that address space is allocated based on CIDR bit 
boundaries (see next section). The registries will need to 
understand your network engineering and deployment plans in 
significant detail before they can allocate address space. 

Therefore, the more detailed information you can provide, the more 
likely your request will be processed quickly. 


If you obtain address space from your ISP, it is very likely that you 
will need to renumber should you decide to change upstream providers 
and/or if you grow considerably. As this renumbering may affect your 
customers (and their customers, etc.) if they are using dedicated 
lines, you should carefully weigh the cost/benefit involved in 
obtaining address space from your upstream provider. 


If you are singly homed, you should obtain your address space from 
your upstream ISP. If you plan on enlarging but remaining singly 
homed, you should continue to obtain space this way as it promotes 
aggregation. If, however, you plan to be multi-homed as part of your 
growth plan, it would make sense to become a member of an appropriate 
Regional IR (or, if one exists in your region, a national Network 
Information Center (NIC) and obtain a /19 or "provider aggregatable" 
address space. 


The minimum routable block is often a /19, so if you plan on 
enlarging, it is better to pay the fees to the Regional IR now and 
obtain a /19 block so that you will not have to renumber later. Note 
that if you are an ISP in the ARIN region, ARIN has special 
requirements before you can do this in terms of the amount of address 
space you have previously used, which must be a /21. The current 
policy is that you must have used a /19 previously from your upstream 
ISP before going to ARIN, or you must be multi-homed and show you 
have used a /21 and be willing to renumber and ARIN will issue a /20 
from a reserved /19. 
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As of February 8, 1999, ARIN lowered the minimum allocation size for 
IP addresses from a /19 to a /20. ARIN will issue initial 
allocations of prefixes no longer than /20. If allocations smaller 
than /20 are needed, ISPs and end users should request address space 
from their upstream provider. ARIN does not guarantee that addresses 
will be globally routable. 


APNIC and RIPE NCC do not have these requirements. For APNIC, new 
allocations to members will be a /19. 


Remember that your upstream provider should route you if you ask 
them. You are a customer of the ISP, so if the service is not what 
you need you should change ISPs. 


IF YOU ARE CONNECTED TO ONLY ONE PROVIDER, AND ARE NOT VERY LARGE 
YET, GET AN ADDRESS RANGE FROM YOUR PROVIDER. SKIP THE REST OF THIS 
SECTION AND ALL OF SECTION V. 


C. What is CIDR? 


CIDR stands for Classless Inter-Domain Routing. Historically, IP 
addresses were assigned within classes: Class A (8 bits of network 
address, 24 bits of host address), Class B (16 bits of network 
address, 16 bits of host address), or Class C (24 bits of network 
address, 8 bits of host address). With the advent of CIDR, address 
space is now allocated and assigned on bit boundaries. Using CIDR 
means you are able to assign addresses corresponding with the number 
of hosts on the network, thereby conserving address space. 


The following table illustrates this: 


Addrs Bits Pref Class Mask 

1 0 /32 255425542554255 
2 1 /31 255.255.255.254 
4 2 /30 2552556255) 252 
8 3 /29 255.255.255.248 
16 4 /28 255.255.255.240 
32 5 /27 255.255.255.224 
64 6 /26 255.255.5255: 2192 
128 7 1:25 255.255.255.128 
256 8 /24 1c 255.255.255.0 
512 9 /23 2¢ 25552552540 
1K 10 /22 4c 255.255.252.0 
2K 11 /21 8C 255.255.248.0 
4K 12 /20 16C 255.255.240.0 
8K 13 /19 32C 255.255.224.0 
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Addrs 
Number of addresses available; note that the number of 
addressable hosts normally is 2 less than this number because 
the host parts with all equal bits (all Os, all 1s) are 
reserved. 
Bits 
Size of the allocation/assignment in bits of address space. 
Pref 
Length of the prefix covering this address space. This is 
sometimes used to indicate the size of an 
allocation/assignment. 
Class 
Size of the address space in terms of class C network numbers. 
Mask 


The network mask defining the routing prefix in dotted quad 
notation. 


(From http://www.ibm.net.il/”~hank/cidr.htm1) 
D. How do I request and register address space? 


You will need to send a database object to the appropriate registry 
to request and register address space. The registration databases 
are composed of records that are a series of fields separated by one 
or more blank lines; each field consists of two parts, the tag and 
the value. Do not modify the tags in the templates or errors will 
occur. Values for particular fields are specified in the templates; 
be careful to enter appropriate information. 


The first line of a template denotes the record type. For example, 
an IP address template’s first line is inetnum, therefore the record 
is known as an inetnum object. This first line is also used as the 
primary key for the record, therefore if you want to modify the first 
field of the record, the only way to do so is to delete the record 
entirely and add a new record with the corrected information. 


For illustration, here is the RIPE inetnum object. 


inetnum: [IP address range that will be assigned] 
netname: Network—-Name 

descr: Network-Name Communications Company, Town 
admin-c: NIC-handle of administrative contact 
tech-c: NIC-handle of technical contact 

country: ISO 3166-country-code 
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rev-srv: ns.someserver.net 

rev-srv: ns.otherserver.net 

status: assigned pa (provider aggregatable) 
or assigned pi (provider independent) 

changed: email@address.net 960731 

source: RIPE 


For Countries in the APNIC Region 


In order to obtain services from APNIC, you will need to become a 
member. APNIC-070 is the APNIC Membership Application. It is 
located at: 


ftp://ftp.apnic.net/apnic/docs/membership-application 
Send the completed form via email to APNIC at: 
member-apply@apnic.net 
APNIC Address Allocation Requests: 


Once you have become a member, you can request IP address space using 
one of the three IP address request forms. If you are an 
organization that will use address space internally only (e.g., large 
enterprises such as universities, government ministries, large 
corporations, etc.), choose #1 (End User Address Request). If you 
are an organization that plans to sub-delegate address space to 
customers (e.g., you are an ISP), choose #2 (ISP Address Request). 

If you are a confederation of ISPs (e.g., national NICs, etc.), 
choose #3 (Confederation Address Request). 


1. APNIC-074 is the APNIC End User Internet Address Request Form. 


2. APNIC-065 is the APNIC Internet Services Provider Internet 
Address Request Form. 


3. Confederations are a means by which service providers can group 
together to provide resource allocation and registration services 
tailored to their specific local language and cultural requirements. 
For details on how to become an APNIC recognized confederation, 
please see APNIC Confederation Concepts and Requirements located at: 


ftp://ftp.apnic.net/apnic/docs/confed-requirements 


APNIC-074 is the APNIC Confederation Internet Address Request Form. 


Wenzel, et al. Informational [Page 11] 


RFC 2901 Administrative Internet Infrastructure Guide August 2000 


Copies of all forms can be found in the following directory: 
ftp://ftp.apnic.net/apnic/docs 
or 
http://www.apnic.net/reg.html 
All completed forms should be sent to: 
hostmaster@apnic.net 
If there are strong reasons why you cannot obtain address space from 
your upstream ISP, and you require address space as a one-time 
allocation only, you can obtain address space as a "non member". For 
more details, see APNIC-O71: 
http://ftp.apnic.net/apnic/docs/non-member-application 
and send the completed form to: 
billing@apnic.net 
For Countries in the ARIN Region 
Membership in ARIN is optional and not a requirement for requesting 
IP address space from the registry or from your Internet service 
provider. If you are a large end user organization, choose #1. If 
you are an ISP, choose #2. 
1. The form for network number assignments is located at: 
ftp://rs.arin.net/templates/networktemplate.txt 
or 


http://www.arin.net/templates/networktemplate.txt 


2. The form for ISPs to obtain a CIDR block of IP network numbers is 
located at: 


ftp://rs.arin.net/templates/isptemplate.txt 
or 

http://www.arin.net/templates/isptemplate.txt 
Send either completed form via email to ARIN at: 


hostmaster@arin.net 


with "IP request" (if you chose #1) or "ISP CIDR request" (if you 
chose #2) in the subject field, as appropriate. 
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IIl. 


A. 


For Countries in the RIPE Region 

RIPE NCC provides IP address space allocation only to contributing 
local Internet registries. For a description of the European 
Internet Registry policies and procedures, see RIPE-159, "European 
Internet Registry Policies and Procedures". It is located at: 


ftp://ftp.ripe.net/ripe/docs/ripe-159.txt 


RIPE-160 is Guidelines for Setting up a Local Internet Registry. It 
is located at: 


ftp://ftp.ripe.net/docs/ripe-160.txt 


If you have questions regarding setting up a new local IR, please 
contact the RIPE NCC at: 


new-lir@ripe.net 


Once your local IR is established, you will get detailed information 
on how to submit requests to the RIPE NCC hostmaster. 


Send the completed form via email to RIPE NCC at: 
nec@ripe.net 
If you have general queries, please contact RIPE NCC at: 
nec@ripe.net 
Section References 
For more information on IP addresses, see RFC 1518, "An Architecture 
for IP Address Allocation with CIDR" and RFC 2050, "Internet Registry 
IP Allocation Guidelines". 
Autonomous Systems (AS) 
STEP THREE: IF NEEDED, OBTAIN AN AUTONOMOUS SYSTEM NUMBER. 
What is an ASN and do I need one? 
Autonomous System Numbers (ASNs) are used to facilitate routing in 
multi-homed environments. They are allocated when your routing 
policy is different from your provider’s. This generally means your 
site is multi-homed. In nearly all cases, unless you are multi-homed 


to more than one ISP, you will not need an ASN. If your routing 
policy does not differ from your service provider’s, you should use 
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the service provider’s ASN. If there is constant traffic between you 
and a point in another country, you may want to connect to a second 
ISP in that country. Note that the resultant multi-homing generally 
makes the system more robust and may also change registry (and 
therefore request) relationships. It also increases costs greatly. 
You may have to reduce traffic on your international lines by 
choosing to connect to a local exchange point. This allows traffic 
to stay within your country and off of expensive international links. 
If you implement this plan, you will be multi-homed and will need to 
read the autonomous systems and routing sections of this document. 

B. How do I register an ASN? 


Since the ASN space is quite limited, request only what you really 
need when you need it. 


For Countries in the APNIC Region 

APNIC-066 is the ASN Request Form. The form is located at: 
http://ftp.apnic.net/apnic/docs/asn-request 

Send the completed form via email to APNIC at: 
hostmaster@apnic.net 

For Countries in the ARIN Region 

A complete listing of assigned ASNs is located at: 
ftp://rs.arin.net/netinfo/asn.txt 

The ASN registration form is located at: 
ftp://rs.arin.net/templates/asntemplate.txt 

or 
http://www.arin.net/templates/asntemplate.txt 

Send the completed form via email to ARIN at: 


hostmaster@arin.net 


with "ASN request" in the subject field. 
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IV. 


For Countries in the RIPE Region 


The European Autonomous System Number Application Form and Supporting 
Notes form (RIPE-147) is located at: 


ftp://ftp.ripe.net/ripe/docs/ripe-147.txt 
Local IRs can send the completed form via email to RIPE at: 
hostmaster@ripe.net 
Section References 


For more information on ASNs, see RFC 1930, "Autonomous Systems 
(AS) ". 


Routing and Exchange Points 


STEP FOUR: IF NEEDED, REGISTER WITH A ROUTING DATABASE. 
Do I need to register with a routing database? 


You do not need to register with a routing database if you are simply 
carrying default routes to your (single) ISP. If you get your 
address space from an ISP, the ISP will register you. If you are 
connected to more than one ISP, then you should register with a 
routing database. 


The more multi-homed you are, the larger your routing tables need to 
be. If you are connected to public exchange points (see examples 
below), or to more than one backbone ISP, you need to carry full 
routing tables and run without a default route. 


Example European Exchange Points: 


LINX London Internet Exchange 
M9-IX Moscow Internet Exchange 
NIX.CZ Neutral Internet Exchange, Czech Republic 


Example Asia/Pacific Exchange Points: 


AUIX Australia Internet Exchange 
HKIX Hong Kong Internet Exchange 
JPIX Japan Internet Exchange 
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Example Americas Exchange Points: 


MAE-EAST Metropolitan Area Ethernet - East 
MAE-WEST Metropolitan Area Ethernet - West 
PAIX Palo Alto Internet Exchange 


Depending on the requirements of your international ISP, you may be 
able to have only a default route to them and specific routes to 
other suppliers if you have an in-country exchange point. Or they 
may require that you carry a full set of routes, treating your 
connection to the in-country exchange point as if it were a multi- 
homed connection. 


B. What about CIDR and routing? 


All registries use CIDR. All major router vendors (Cisco, 3Com, 
Nortel, Proteon, IBM, etc.) support CIDR. CIDR Internet routers use 
only the prefix of the destination address to route traffic toa 
subnetted environment. 


C. How do I choose a routing database? 


The Internet Routing Registry (IRR) describes registries maintained 
by several national and international networking organizations. 
These currently include the RIPE Network Coordination Centre (NCC), 
ANS (Advanced Network Solutions, Inc.), Bell Canada (formerly 
CA*net), Cable and Wireless (CW), and the Routing Arbiter Database 


(RADB). The IRR is a way for ASNs to publicize their own intended 
routing policies without having to request a change from a go- 
between. 


"whois" queries to "whois.ra.net" return data that they gather from 
the entire IRR set of routing registries. Tools such as "peval" and 
"rtconfig" return data only from the RADB. Thus, when running those 
tools and desiring data from a set of registries, one must enumerate 
them as in the following example. "whois" queries to the client 
configure the precedence of routing databases. For example: 


@RtConfig set sources = "TEST, RADB, RIPE, ANS, BELL, CW" 


There are several other registries, such as ALTDB. A list, and other 
information on RADB, is available at: 


http: //www.radb.net/ 
As of January 1, 2000, the transition to the Routing Policy 


Specification Language (RSPL) is complete. RIPE-181 object 
submissions are no longer accepted. For more information, see: 
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http://www.merit.edu/radb/announce.html 


With the exception of the Routing Arbiter Database, each registry 
serves a limited customer base. ANS, Cable and Wireless, and Bell 
Canada accept routing registrations for their customers alone, and 
the RIPE NCC oversees European registrations. The Routing Arbiter 
Database is unique in that it handles registrations for networking 
organizations not covered by the other routing registries. The 
Routing Arbiter also provides coordination among all the registries 
to ensure consistent representation of routing policies. 


All Regional IRs need to register with one (only one) of the routing 
databases in the IRR. If you are announcing routes via BGP4, you need 
to register your routes in the Routing Registry in only one of the 
IRR’s. Logically, this will be the "closest" IRR to you. However, 
note that some ISPs do not use the regional registries or RADB. 

D. How do I register in the RADB (The Americas) ? 
You need to submit three types of database records to the RADB: one 
or more maintainer objects, an AS object, and one or more route 
objects. 
To specify the individuals who are allowed to update your records in 
the RADB, fill out one or more maintainer objects and send them via 
email to: 


db-admin@radb.net 


You need to submit a maintainer object before you can register any AS 
or route objects. 


To describe the autonomous system that announces your routes, fill 
out an AS object and submit it via email to: 


auto-dbm@radb.net 
AS objects are also called aut-num objects. 


To register your routes, fill out one or more route objects, and send 
them to RADB via email to: 


auto-dbm@radb.net 


Note that most of the IRR participants have the auto-dbm@xx.net email 
address function for accepting updates to the IRR automatically. 
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E. Section References 
For more information on routers, see RFC 1812, "Requirements for IP 
Version 4 Routers". See also RFC 1786, "Representation of IP Routing 


Policies in a Routing Registry (ripe-181++)". 


For more information on CIDR and routing, see RFC 1817, "CIDR and 
Classful Routing". 


V. Domain Name Registration 


STEP FIVE: REGISTER YOUR DOMAIN NAME. 


A. What is a country domain? 


The Domain Name System (DNS) specifies the naming of computers within 
a hierarchy. Top-Level Domain (TLD) names include generic TLDs 
(gTLDs) and two-letter country codes (ccTLDs). Examples of gTLDs 
include .com (commercial), .net (network), and .org (organization). 
Examples of two-letter country codes are .ca for Canada, .fr for 
France, and .id for Indonesia. ISO 3166 is used as a basis for 
country code top-level domain names. Country codes are assigned by 
the International Organization for Standardization (ISO) in 
cooperation with the United Nations. The Internet Assigned Numbers 
Authority (IANA) directly registers all country-code top-level 
domains, however it is not involved in the allocation of codes to 
countries. IANA is a function of the Internet Corporation for 
Assigned Names and Numbers (ICANN, see Appendix A). See ISO 3166 for 
more information and a current listing of country codes (Appendix C). 


A hierarchy of names may, and normally should be, created under each 
TLD. There is a wide variation in the structure of country domains. 
In some countries there is a substantial hierarchy, while in others 
the structure is flat. In some country domains the second levels are 
generic categories, while in others they are based on geography, and 
in still others, organization names are listed directly under the 
country code. Examples of second level generic categories are ac or 
edu (academic or education), co or com (corporate or commercial), and 
go or gov (government). 


B. How do I register as a country domain? 


First check that: (1) the domain is still available, few are, (2) you 
have someone in your country as the administrative contact, and (3) 
your name servers are prepared (see RFC 1912 for information on 
common errors in preparing name servers). 
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Vi. 


The whois master database is the authoritative source of information 
on .com, .net, .org, and .edu domain name registrations. It is 
currently maintained by Network Solutions, Inc. and holds referral 
pointers to which whois database contains the record for the domain 
name. 


To apply to manage a country code top-level domain you should: 


1. First, if you are on a UNIX host, use the "whois" command to see 
if the domain is already registered: 


whois =<domain> 


2. If the domain does not already have an administrative contact, 
request a Domain Name Agreement template from IANA by sending email 
to: 


iana@iana.org 
What if my country is already registered? 


If your country is already registered, contact the country-code 
administrator to register a new second-level domain name. 


Please note that ARIN, RIPE, and APNIC do not handle domain names 
(other than IN-ADDR.ARPA). If you want to register a domain name 
directly under a top-level domain (TLD), please contact the 
appropriate TLD administrator. 


How do I resolve a country domain name dispute? 

See RFC 1591 for domain name dispute information. Note that you will 
need to resolve the dispute within your country before you contact 
IANA. 

Section References 
For more information on domain names, see RFC 1591, "Domain Name 
System Structure and Delegation"; RFC 1713, "Tools for DNS 
Debugging"; and RFC 1912, "Common DNS Operational and Configuration 
Errors". 


IN-ADDR.ARPA Domain Delegation 


STEP SIX: IF NEEDED, REGISTER YOUR IN-ADDR.ARPA DOMAIN. 
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A. What is an IN-ADDR.ARPA domain and do I need one? 


An IN-ADDR.ARPA domain allows for mapping of IP addresses into domain 


names. This is often referred to as "inverse addressing" because it 
is the opposite of the domain name to IP address resolution. IN-ADDR 
domains are represented using the network number in reverse. For 


example, the IN-ADDR domain for network 123.45.67.0 is represented as 
67.45.123.in-addr.arpa. 


You almost always need reverse resolution. 

B. How do I register an IN-ADDR.ARPA domain? 
You should ask your upstream provider about registering your IN- 
ADDR.ARPA domains. If you are working directly with a regional 
registry, see below. 
For Countries in the APNIC Region 
The IN-ADDR.ARPA Delegation Form is APNIC-064 and is located at: 


ftp://ftp.apnic.net/apnic/docs/in-addr-request 


CAUTION: You must set-up your name server to accept the delegation 
prior to submission of this form. 


Send the completed form via email to APNIC at: 
domreg@rs.apnic.net 
For Countries in the ARIN Region 
How IN-ADDR.ARPA is registered is dependent on the registration of 
the block needing reverse entries. For example, all blocks that have 
been registered directly from the Regional IR may have IN-ADDR.ARPA 
delegation established by ARIN. In this case, IN-ADDR.ARPA 
delegations are registered using the ARIN modify template. This 
template can be found at: 
ftp://ftp.arin.net/templates/modifytemplate.txt 
or 


http://www.arin.net/templates/modifytemplate.txt 


Instructions for completing the template can be found at the bottom 
of the template. 


CAUTION: Do not list your network number in reverse on the template. 
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VII. 


A. 


Send the completed form via email to ARIN at: 
hostmaster@arin.net 


All blocks that have been reassigned to your organization by an ISP 
will have IN-ADDR.ARPA established by your provider. In this case, 
contact the ISP that reassigned IP address space to your organization 
and coordinate IN-ADDR.ARPA delegation. 


For Countries in the RIPE Region 


The domain object needs to be entered in the RIPE database before 
requesting reverse delegation. 


domain: 0.194.in-addr.arpa 

descr: Our organization allocation 

admin-c: NIC-handle of administrative contact (e.g., JLC-2RIPE) 
tech-c: NIC-handle of technical contact 

zone-c: NIC-handle of zone contact 

nserver: Name server (e.g., ns.someserver.net) 

nserver: ns.otherserver.net 

nserver: ns.ripe.net 

changed: email@address.net 960731 

source: RIPE 


NOTE: One of the name servers has to be ns.ripe.net 


The domain object described above should be included in the request, 
as well as zone file entries for the zone above the one requested. 
For example, if a reverse delegation is requested for 1.193.in- 
addr.arpa, the relevant zone file entries should be included for 
193.in-addr.arpa; whereas if a reverse delegation is requested for 
2.2.193.in-addr.arpa, the zone file entries should be included for 
2.193.in-addr.arpa. 


Send the completed object(s) via email to RIPE at: 
auto-inaddr@ripe.net 
Security 
Is there a way to prevent unauthorized changes to my objects? 
Registries provide various security measures to prevent unauthorized 
changes to your database entries. Contact your regional IR for more 


information. Note that the contact information you provide in the 
database object registrations is not private. 
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VIII. Network Optimization and Management 
A. How do I optimize traffic on my network? 


Contact the Cooperative Association for Internet Data Analysis 
(CAIDA). CAIDA is a collaborative undertaking to promote greater 
cooperation in the engineering and maintenance of a robust, scalable 
global Internet infrastructure. CAIDA provides a neutral framework 
to support these cooperative endeavors. 


The CAIDA web-site is located at: 
http://www.caida.org/ 
Send email with questions or comments to: 
info@caida.org 

Security Considerations 
Security is discussed in section VII. 
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Appendix A: The Internet Agencies 
o The Internet Assigned Numbers Authority (IANA) 


IANA is the central coordinator for the assignment of unique 
parameter values for Internet protocols and for all address space and 
name space used in the Internet. IANA allocates parts of the 
Internet address space to Regional Internet Registries (IRs) for 
distribution to Local IRs and ISPs. IANA is also responsible for the 
coordination and management of the Domain Name System (DNS). 


Note that as of 1999, IANA is a function of the Internet Corporation 
for Assigned Names and Numbers (ICANN), the non-profit corporation 
that is the top-level administration authority of the global 


Internet. 

Email: iana@iana.org 

Postal: 4676 Admiralty Way, Suite 330 
Marina del Rey, CA 90292 
USA 

Telehone: +1-310-823-9358 

Fax: +1-310-823-8649 

Internet: http://www.iana.org/ 


o Internet Corporation for Assigned Names and Numbers (ICANN) 
From the ICANN web site: 


The Internet Corporation for Assigned Names and Numbers (ICANN) is a 
technical coordination body for the Internet. Created in October 1998 
by a broad coalition of the Internet’s business, technical, academic, 
and user communities, ICANN is assuming responsibility for a set of 
technical functions previously performed under U.S. Government 
contract by IANA and other groups. 


Specifically, ICANN coordinates the assignment of the following 
identifiers that must be globally unique for the Internet to 
function: Internet domain names, IP address numbers, protocol 
parameter and port numbers. In addition, ICANN coordinates the 
stable operation of the Internet’s root server system. 


As a non-profit, private-sector corporation, ICANN is dedicated to 
preserving the operational stability of the Internet; to promoting 
competition; to achieving broad representation of global Internet 
communities; and to developing policy through private-sector, 
bottom-up, consensus-based means. ICANN welcomes the participation 
of any interested Internet user, business, or organization. 
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Email: icann@icann.org 
Postal: Internet Corporation for Assigned Names and Numbers 
(ICANN) 


4676 Admiralty Way, Suite 330 
Marina del Rey, CA 90292 


USA 
Telehone: +1-310-823-9358 
Fax: +1-310-823-8649 
Internet: http://www.icann.org/ 


o InterNIC 


The InterNIC was a cooperative activity between the National Science 
Foundation, General Atomics, AT&T, and Network Solutions, Inc. The 
joint activity InterNIC no longer exists. 


Currently, Network Solutions runs the central registry according to 
the shared registry model specified by ICANN for registration of 
second-level domain names under the generic top-level 

domains .com, .net, and .org. 


For information on accredited registrars for .com, .net, and .org, 
please see: 


http://www.icann.org/registrars/accredited-list.html 


(note that Network Solutions is an accredited registrar as well as 
the entity running the registry). 


Email: hostmaster@netsol.com 

Postal: Network Solutions, Inc. 
505 Huntmar Park Dr. 
Herndon, VA 20170 US 


Telephone: +1-703-742-4777 
Fax: +1-703-742-9552 
Internet: http://www.networksolutions.com/ 


Regional Internet Registries (IRs) 


Regional IRs operate in large geopolitical regions such as 
continents. Currently, there are three Regional IRs: ARIN for the 
Americas, the Caribbean, and Africa; RIPE NCC for Europe, Africa, and 
the Middle East; and APNIC for the Asia Pacific region. The specific 
duties of the Regional IRs include coordination and representation of 
all local Internet Registries in their respective region. 
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o APNIC 


Asia Pacific Network Information Center (APNIC) is a non-profit 
Internet registry for the Asia Pacific region. APNIC provides IP 
address allocation, Autonomous System Number (ASN) assignment, and 
IN-ADDR.ARPA registration. 


Email: hostmaster@apnic.net 
Postal: APNIC Box 2131 
Milton Queensland 4064 
Australia 
Telephone: +61-7-3367-0490 
Fax: +61-7-3367-0482 
Internet: http://www.apnic.net/ 
o ARIN 


The American Registry for Internet Numbers (ARIN) is a non-profit 
Internet registry that was established for the purpose of 
administration and registration of Internet Protocol (IP) numbers to 
the geographical areas that were previously managed by Network 
Solutions, Inc. These areas include, but are not limited to, North 
America, South America, Africa, and the Caribbean region. ARIN 
provides IP address allocation, Autonomous System Number (ASN) 
assignment, and IN-ADDR.ARPA registration. 


Email: hostmaster@arin.net 
Postal: 4506 Daly Drive 
Suite 200 
Chantilly, VA 20151 
Telephone: +1-703-227-0660 
Fax +1-703-227-0676 
Internet: http://www.arin.net/ 
o RIPE NCC 


Reseaux IP Europens Network Coordination Centre (RIPE NCC) is a non- 
profit Internet registry for the European, North African, and Middle 
East regions. RIPE NCC provides IP address allocation, Autonomous 
System Number (ASN) assignment, and IN-ADDR.ARPA registration. 


Email: nec@ripe.net 
Postal: Singel 258 
1016 AB Amsterdam 
The Netherlands 


Phone: +31-20-535-4444 
Fax: +31-20-535-4445 
Internet: http://www.ripe.net/ 
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Appendix B: Documentation 
Internet Documentation 


For general Internet documentation, "ftp" to rfc-editor.org and "cd" 
to the /rfc subdirectory for Request for Comments documents. 


Details on obtaining these documents via ftp or email may be obtained 
by sending an email message to: 


rfc-info@rfc-editor.org 
with the message body help: ways_to_get_rfcs. For example: 


To: rfc-info@isi.edu 
Subject: getting rfcs 


help: ways_to_get_rfcs 
Documents, Templates, and Forms 


The documents, templates, and forms referenced in this guide are 
available from the document stores in the directories listed in the 
URLs (Uniform Resource Locators). Organizations without connectivity 
wishing to obtain copies of the referenced documents should contact 
their Local IR to arrange postal delivery of one or more of the 
documents. Note that fees may be associated with the delivery of 
hardcopy versions of documents. 


The document stores can be accessed in two ways: 
1. Via anonymous FTP (File Transfer Protocol). 


Using your ftp program, connect to the appropriate host computer 
shown below using your email address as the password. Use the "cd" 
(change directory) command to connect to the appropriate 
subdirectory, then use the "get" command to retrieve the specific 
file. For example: 


ftp rs.apnic.net (for countries in the Asia/Pacific region) 
ftp rs.arin.net (for countries in the Americas) 


ftp rs.ripe.net (for countries in Europe or North Africa) 


login: anonymous 
password: your_email_address 


cd netinfo 
get <domain>_info.txt 
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2. Via electronic mail, ftp, or the World Wide Web. 


Send email to the appropriate address shown below with the message 
body as specified. 


APNIC Documentation 
For APNIC documents and templates, "ftp" to ftp.apnic.net and "cd" to 
/apnic/docs. APNIC no longer has an electronic mail method of form 
retrieval. Many of APNIC’s request forms are also available on the 
web site at: 
http://www.apnic.net/reg.html 
ARIN Documentation 
For ARIN templates, "ftp" to rs.arin.net and "cd" to /templates. 
You can also obtain templates via the web site at: 
http://www.arin.net/templates.html 
Other ARIN documentation is available at: 
http://www.arin.net/docs.html 
Or send email to: 
hostmaster@arin.net 


RIPE Documentation 


For RIPE documents and forms, "ftp" to ftp.ripe.net/ripe and "cd" to 
/docs or cd to /forms. 


Or send email to: 


mail-server@ripe.net 
with send help in the body of the message. 
Appendix C: Country Codes 
The International Organization for Standardization (ISO) 3166 
Maintenance Agency and ISO 3166 current list of two-letter country 


codes is available via: 


http://www.iso.ch/infoe/agency/3166-1.htm 
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Appendix D: 


ANS 
ASN 
APNIC 
ARIN 
AS 
CANET 
CIDR 
DNS 
gTLD 
IANA 
InterNIC 
IP 

IR 

IRR 

ISO 

ISP 

LINX 

NCC 

NIC 

NSRC 

POP 

RADB 

REC 

RIPE 
TCP/IP 
TLD 
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Acronyms 


Advanced Network Services, Inc. 
Autonomous System Number 

Asia Pacific Network Information Center 
American Registry for Internet Numbers 
Autonomous System 

Canada Net 

Classless Inter-Domain Routing 

Domain Name System 

Generic Top-Level Domain 

Internet Assigned Numbers Authority 
Internet Network Information Center 
Internet Protocol 

Internet Registry 

Internet Routing Registry 

International Organization for Standardization 
Internet Service Provider 

London Internet Exchange 

Network Coordination Centre 

Network Information Center 

Network Startup Resource Center 

Point of Presence 

Routing Arbiter Data Base 

Request for Comments 

Reseaux IP Europeans 

Transmission Control Protocol/Internet Protocol 
Top-Level Domain 


2000 
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Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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